Dynomotion

Group: DynoMotion Message: 13886 From: Hardy Family Date: 10/14/2016
Subject: Kflop usb protocol needs reset function
Hi Tom,

One of the frustrations we have trying to get rock solid connections from the pc to the kflop is that if something crashes (on the host), the kflop sometimes is left in the middle of a transaction or is otherwise unable to sync up.  When the PC side is restarted, it cannot resync.  I just shut everything down then try again, but we don't want our customers to have to do this.  Bad enough when our software crashes, but really bad if it can't just start up again.

Maybe this is a bug in our KMotionServer implementation, but it would be nice if, when opening the USB connection, the server could send out some binary sequence that the kflop is guaranteed to accept and cause it to reset its USB comms state machine.

For example, we could send out null characters (0x00) until the kflop responds with a null.  Then we would know we're in sync.  Or maybe we just send out a null after opening the usb device and hope for the best.

Regards,
SJH
Group: DynoMotion Message: 13892 From: Tom Kerekes Date: 10/14/2016
Subject: Re: Kflop usb protocol needs reset function

Hi SJH,

Such a mechanism already exists.  I'm not sure why it isn't working for you.  See the function:

int CKMotionIO::FlushInputBuffer()

Sending an 0x03 character to KFLOP should immediately cause it to discard all data in its input buffers and respond with 3 characters:\

ESC C \r


After any interrupted communication or data corruption calling the function:

int CKMotionDLL::Failed()

Should cause the interface to flush and reset before the next interaction.

HTH

Regards

TK


On 10/14/2016 12:51 PM, Hardy Family hardy.woodland.cypress@... [DynoMotion] wrote:
 
Hi Tom,

One of the frustrations we have trying to get rock solid connections from the pc to the kflop is that if something crashes (on the host), the kflop sometimes is left in the middle of a transaction or is otherwise unable to sync up.  When the PC side is restarted, it cannot resync.  I just shut everything down then try again, but we don't want our customers to have to do this.  Bad enough when our software crashes, but really bad if it can't just start up again.

Maybe this is a bug in our KMotionServer implementation, but it would be nice if, when opening the USB connection, the server could send out some binary sequence that the kflop is guaranteed to accept and cause it to reset its USB comms state machine.

For example, we could send out null characters (0x00) until the kflop responds with a null.  Then we would know we're in sync.  Or maybe we just send out a null after opening the usb device and hope for the best.

Regards,
SJH
Group: DynoMotion Message: 13894 From: Hardy Family Date: 10/14/2016
Subject: Re: Kflop usb protocol needs reset function
Ah, so that's what that code is for.  Got it.  I'm using the Linux port and sometimes it's a little unclear what each function does.

Regards,
SJH


On Fri, Oct 14, 2016 at 2:01 PM, Tom Kerekes tk@... [DynoMotion] <DynoMotion@yahoogroups.com> wrote:
 

Hi SJH,

Such a mechanism already exists.  I'm not sure why it isn't working for you.  See the function:

int CKMotionIO::FlushInputBuffer()

Sending an 0x03 character to KFLOP should immediately cause it to discard all data in its input buffers and respond with 3 characters:\

ESC C \r


After any interrupted communication or data corruption calling the function:

int CKMotionDLL::Failed()

Should cause the interface to flush and reset before the next interaction.

HTH

Regards

TK


On 10/14/2016 12:51 PM, Hardy Family hardy.woodland.cypress@gmail. com [DynoMotion] wrote:
 
Hi Tom,

One of the frustrations we have trying to get rock solid connections from the pc to the kflop is that if something crashes (on the host), the kflop sometimes is left in the middle of a transaction or is otherwise unable to sync up.  When the PC side is restarted, it cannot resync.  I just shut everything down then try again, but we don't want our customers to have to do this.  Bad enough when our software crashes, but really bad if it can't just start up again.

Maybe this is a bug in our KMotionServer implementation, but it would be nice if, when opening the USB connection, the server could send out some binary sequence that the kflop is guaranteed to accept and cause it to reset its USB comms state machine.

For example, we could send out null characters (0x00) until the kflop responds with a null.  Then we would know we're in sync.  Or maybe we just send out a null after opening the usb device and hope for the best.

Regards,
SJH
Group: DynoMotion Message: 14251 From: par.hansson80 Date: 12/8/2016
Subject: Re: Kflop usb protocol needs reset function
Hi SJH

I have experienced the same problem on Mac OS. 
If you look in CKMotionIO::FlushInputBuffer() there is bit of a hack just for Mac OS that seems to kickstart the communication on a second attempt.

The code is in my master branch.

Maybe there is something wrong with libusb. If you are not using libusb the problem might be in the OS USB-stack. I haven't figured this out myself. However by sending just anything to the usb device before the abort character seems to make it work.  I use "ReadBit0" just to send be sure it is something that Kflop understands. 
 


Regards PH